Stack Roster Fantasy Sports Game and Platform

ABSTRACT

A method and system for playing a fantasy sport competition among a plurality of Users, includes instructions stored on a non-transitory computer readable medium for transmitting User selections to suitably order Players in the User roster comprising a User prioritized list of Players according to positions, such that for each position the User has reflected a plurality of choices in order of User preference. A server receives Invited User rosters from each Invited User. Each Invited User roster includes that Invited User&#39;s prioritized list of Players according to positions. To create Stack Roster pairings, the User is compared with each Invited User and each Invited User with each other. Where two Users select a single player for the same position within a Stack Roster pairing, the system and method move on to compare both Users&#39; next selection of Player at a position, until each can be given their choice of Player.

PRIORITY CLAIM

This application claims the benefit of provisional application Ser. No.61/840,303 filed Jun. 27, 2013, the contents of which are incorporatedby reference.

FIELD OF THE INVENTION

The present invention is a game played by several players on a networkand more specifically a fantasy sports game.

BACKGROUND OF THE INVENTION

Fantasy sports have enjoyed a longer and more consistent growth over thethree decades since they were introduced largely due to their inherentorality. Virality is a metric that has been borrowed from the field ofepidemiology. It pertains to how quickly an element or content spreadsthrough the population. Because of their reliance on public statisticsgenerated either daily or weekly, are inherently asynchronous, which isto say that they do not require any two persons competing thereby to becommunicatively connected to each other to play. Even more importantly,they rely upon and foster growth of a community of competitors, i.e.competition is only possible if a User “shares” his game with friends.

For purposes of clarity within this discussion, two terms will bedefined that may or may not have their normal meaning to the reader.There is an inherent confusion in the use of the word “player” infantasy sports, as so many sports that lend themselves to fantasy playrefer to athletes as “players”. To curb the occasion of such confusion,two words will be used throughout to have the meanings set out here:

“User”—An individual, registered on a server, who engages in game playas a manager competing within any fantasy sport hosted on the server.

“Instigating User”—One of the Users who designates at least one otherUser (herein “Invited User”) to the server, thereby to initiate afantasy sports competition.

“Player”—Any athlete or other individual competing in a real-livesporting event from which statistics are garnered, examples of which arebaseball players, basketball players, soccer players, football players,race car drivers/race cars, mixed martial artists, etc.

“Season” is any defined interval of competition between Users; as usedherein, the season may coincide with a season as recognized by thegoverning authorities of the various sports or it may be one defined bythe Users, such as a single day of competition. Seasons can even spanmultiple years, if the Users so define the Season. Any interval of playfor which statistics can be reliably garnered the Users can define as aseason.

Fantasy sports often involves team sports and the draft process requiresvarious player positions to be filled. The number of Players a Userclaims is dependent upon the rules of the sport the Player is playingand/or the manner in which each individual fantasy sports game isdevised, and would therefore be any number of Players.

Fantasy sports are any of several games where Users manage a roster ofPlayers drawn from any group for whom statistics are compiled. In eachof the possible sports ranging from NFL football to MLS soccer to NASCARracing and those many other sports for which news sources publishstatistics, a fantasy sport game exploiting those statistics can bedevised. Users rely upon their ability to acquire and field a team ofathletes pursuant to such rules as the group of Users define or adopt.Users compete against one another receiving points for their acquiredPlayers' real life statistics as the Players compete in their real lifesports. Any injury or other impediment a Player suffers in the season isreflected in the resulting statistics a Player garners for the season inquestion. Similarly, any particularly good performance will shift aPlayer's statistics upward. In short, just as a real-life generalmanager in a sport must contend with the vagaries of the performance ofhuman athletes that make up his team, so, too, does the fantasy sportsUser. As such, the fantasy player User gets to sample, vicariously, thesensations ABC™ Sports touts as the “thrill of victory and the agony ofdefeat” by imparting a personal stake in each Player's performance.

The advent of powerful computers and the Internet revolutionized fantasysports, allowing scoring to be done entirely by computer, and, thereby,allowing leagues to develop their own scoring systems, often based onless popular statistics. In this way, for example, fantasy baseball hasbecome a sort of real-time simulation of baseball, and allowed many fansto develop a more sophisticated understanding of how the real-world gameworks. According to statistics from a 2009 article in Forbes, nearly 11million people play fantasy baseball today, in all fantasy sports, AdWeek estimates nearly 32 million people.

Generally, as the play in all fantasy sports centers on the manager'sstaffing decisions, the teams are rated on the performance of each of aroster of athletes and the associated statistics they accumulate as theseason progresses. As such, the original draft and subsequent tradespresent User managers with their scoring opportunities. Users, asmanagers, often draft teams before the season begins (or very shortlythereafter). One conventional approach is to hold an auction, wherebyeach User as manager has a fixed amount of money to bid for athletes,and he must fill his team's roster within their budget. Anotherconventional approach is to perform a serpentine system draft ofavailable athletes until all teams are filled. Because selecting andtrading athletes is the key issue that defines the play of any fantasysports game relative to mark performance as against other manager Users,each variant that changes that process creates a distinct game.

Conventionally, fantasy sports have User's organized into leagues. Onesuch league in fantasy baseball is known as the Roach Motel League,founded in 1981 at Columbia University in New York. Original RotisserieLeague member Glen Waggoner was an administrator at Columbia and hepassed along the rules to a group of undergraduates. The Roach MotelLeague, still consisting primarily of original members, has held a draftand played the game every year since 1981. But, absent such aninfrastructure, there is no good way to organize head-to-head orthree-way competition where there is not enough available Users topopulate an entire league. Because league play is also rather slow, itwould be advantageous for any user to have the opportunity to play inseveral distinct groups. Nonetheless, a User may not wish to order theirchoices to actually participate in distinct Player drafts for eachgroup. What is needed in the art is a means of instantaneously formingteams of Players around each User's own selections without the need fordistinct traditional style drafts to enable play in each group.

SUMMARY OF THE INVENTION

A method and system for playing a fantasy sport competition among aplurality of Users, includes instructions stored on a non-transitorycomputer readable medium for transmitting User selections to suitablyorder Players in the User roster comprising a User prioritized list ofPlayers according to positions, such that for each position the User hasreflected a plurality of choices in order of User preference. A serverreceives Invited User rosters from each Invited User. Each Invited Userroster includes that Invited User's prioritized list of Playersaccording to positions. To create Stack Roster pairings, the User iscompared with each Invited User and each Invited User with each other.Where two Users select a single player for the same position within aStack Roster pairing, the system and method move on to compare bothUsers' next selection of Player at a position, until each can be giventheir choice of Player.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred and alternative examples of the present invention aredescribed in detail below with reference to the following drawings:

FIG. 1A is a graphical representation of first step in an exemplaryinterface for enabling a Stack Roster “draft” for a fantasy sports game;

FIG. 1B is a graphical representation of second step in an exemplaryinterface for enabling a Stack Roster “draft” for a fantasy sports game;

FIG. 1C is a graphical representation of third step in an exemplaryinterface for enabling a Stack Roster “draft” for a fantasy sports game;

FIG. 2 is a graphical representation of the resulting roster in anexemplary interface for enabling a Stack Roster “draft” for a fantasysports game;

FIG. 3 is a graphical representation of a challenge to initiate play inan exemplary interface for enabling a Stack Roster “draft” for a fantasysports game;

FIGS. 4A1, 4A2, and 4A3 are a graphical representation of a process ofroster reconciliation of rosters in an exemplary Stack Roster “draft”for a fantasy sports game;

FIG. 4B is a graphical representation of a scheme for scoring during a“season” in an exemplary interface for enabling a Stack Roster “draft”for a fantasy sports game;

FIG. 4C is a graphical representation of sample scoring during a“season” in an exemplary interface for enabling a Stack Roster “draft”for a fantasy sports game;

FIGS. 5A, 5B, and 5C are a block diagram representation of a datastructure in an exemplary interface for enabling a Stack Roster “draft”for a fantasy sports game; and

FIG. 6 is a block diagram of a computer network enabling a Stack Roster“draft” for a fantasy sports game.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

As has been indicated above in the Background section, the event thatdefines fantasy sports play is the User's selection of Players. Ratherthan to begin the explanation of the invention with a description of themechanics that enable a User's selection of Players for play in a groupof Users, beginning the description at a higher level will make thelater description of those mechanics much more understandable.Understanding that the invention is practiced on a network such as theInternet by interaction with an interface that is generally representedin interaction with the User in FIGS. 1 through 9.

Beginning with a User's eye view of the process at FIG. 1, anInstigating User, after appropriately signing into the system, providingsuch information and funds as are necessary to qualify forparticipation, is presented with an interface screen 100 having twoprincipal features, generally similarly configured roster elements: 1) aPlayer pool 101; and 2) a User Team Roster. In the presently preferredembodiment, these roster elements are as shown, but the invention couldbe practiced with graphic elements that display players identities suchas tile-like icons shown in FIG. 1A and referred to as “tiles” 105B,105C, and 105D and graphically represented receptacles to receive thosetiles referred to as “slots”. While these same functions could as easilybe represented in a range of graphic representations, even in a simplestform in textual lists representing each of the Player pool 101 and theUser team roster 103, the graphic representations shown in FIG. 1A ismost readily adapted to this explanation of game play.

The Player pool in this embodiment is further divided by positions. Forexample, such positions might include a quarterback, a running back, awide-receiver and a tight end in NFL™ football and, by contrast, apitcher, a catcher, and a first baseman, etc. in MLB™ baseball.Similarly each sport would have its own designation for such positions.In order to facilitate display identities of the numerous players thatwould make up a roster, the configuration of the presently preferredembodiment may optionally be divided into pages, each page representinga position as the sport defines it. Thus the pool 101 is divided intopages such as 101P1, 101P2 etc. while the User team roster is similarlydivided into pages such as 103P1, 103P2, etc. Advantageously, in thepresently preferred embodiment, selecting a page on one of the pool 101or the roster 103 will result in both the pool 101 and the roster 103displaying the corresponding pages, e.g. selecting page 2 in the rosterwill cause page 2 to display in each of the roster and the pool.

In some sports, such as NASCAR™ auto racing, generally only driversreceive recognition with published statistics and so there are nodistinct positions but rather a team comprising several drivers. Forsuch sports, the pool 101 and the roster 103 may not be divided intoindividual positions as there is no useful distinction that would makesuch a division useful. In such a case, the position would not benecessary or included to selectively display distinct portions of theroster 103 and the pool 101.

A User must now populate the Instigating User's team roster 103 from thePlayer candidates listed in the pool 101. Once again, the presentlypreferred embodiment involves moving tiles 105B, 105C, and 105D from thepool 101 to the Instigating Users team roster 103 to occupy one of theslots 107A, 107B, 107C, 107D, 107E, and 107F; the invention is not solimited as the invention may be practiced in several alternateembodiments, including, as discussed above, so simple an interface astextual lists. The presently preferred embodiment is described toillustrate movement of Players from the pool 101 to the User's teamroster 103 and further to illustrate prioritization of the User's teamroster 103, through the use of tiles 105B, 105C, and 105D and slots107A, 107B, 107C, 107D, 107E, and 107F as enabling a graphical userinterface.

A User populates the team roster 103, As shown in FIG. 1B by dragging atile in a selecting move 109, in this case tile 105B to one of thevacant slots, in this case 107A, on the User team roster 103 and as aresult achieves at least two of the instant invention's constituentsteps, one of selecting a Player and one of placing a priority on thePlayer. Additionally, further moves 109 may occur as are dictated invarious embodiments of the instant invention. For example, each Playermay have a value attached to the player, the value being the price ofacquiring the Player, analogous to salaries in real life sports or eventhe actual annual contractual salary of the Player. At this point, thevalues are merely noted in this embodiment and are subject to subsequentsteps when an actual User's team roster is determined by thereconciliation described below. These values place additional realisticconstraints on the User in forming teams, thereby further mimickingconstraints on real-life team managers, as will be further explainedbelow.

The graphic interface 100 inherently presents certain advantages in thatthe movement of tiles such as tile 105B inherently removes the playerfrom the pool 101 to the roster 103 preventing duplicate designations ofPlayers as being on the User's team roster 103.

The User continues selecting Players in the manner described above untilall of the slots 107A, 107B, 107C, 107D, 107E, and 107F. (Six slotsbeing shown only as a non-limiting example; the invention can bepracticed with more or fewer slots as selected rules may dictate). TheUser may also move a Player tile 105B from one slot 107A to another slot107C to adjust priority among the several choices until all six of theslots 107A, 107B, 107C, 107D, 107E, and 107F are filled and orderedaccording to the priority the User places on each Player. Likewise, theUser progresses through each of the positions, moving from page 101P1through 101P7 of the pool and similarly through pages 103P1 through103P7. The interface works to afford the User suitable opportunity tomake selections and set priorities throughout the User team roster.

Referring to FIG. 1C, at some point, the User has completely populated,reviewed and prioritized the User's team roster 103 by filing, in thisnon-limiting case slot 107A with Player B's tile 105B, slot 107B withPlayer A's tile 105A, slot 107C with Player C's tile 105C, slot 107Dwith Player F's tile, slot 107E with Player E's tile 105E, slot 107Fwith Player D's tile 105D and has similarly filed each of the otherplayer positions 103P2, 103P3, 103P4, 103P5, 103P6 and 103P7 to populateeach to reflect selections and organize the selections at each positionaccording to the User's priorities. Having suitably filled the roster103, the User executes a save by clicking 111 the “Save” button on theroster 103.

Depicted in FIG. 2, the roster 103 has a structure indicating Userselections and prioritization. The top line picks illustrated hererepresent the User's desired “starting lineup” 103V (1^(st) or top picksfor each player position) for competition against other Users.Ultimately, the actual Players that represent the User in fantasycompetition are determined by the “Stack Roster Match Up” process, whichis described below and which is initiated when one Instigating Userinvites one or many other Invited Users to engage in competitive fantasygame play. In actual play, it will be a rare occasion where a User willget all of his intended first lineup 103V but such would happen in therare case where the User would select as first picks Players no otherUser had selected. The data structure of the roster 103 is made clear bythe graphic portrayal: along the x-axis, positions are set forth in amanner determined by the platform and along the y-axis, players areordered at each position in accord with the preferences of the User withthe most favored having the top position. (For the sake of disclosure,there is nothing in the inherent structure of the invention or itspractice that requires that the number of picks be the same for eachposition. As rules are adopted for each fantasy sport, the number ofpicks can, likewise, be adopted, resulting in a data structure matrixthat may not match a perfect rectangle in rank and file).

As FIG. 3 depicts, having once assembled a User team roster 103A, thevery quality of the instant invention is the inherent virality possibledue to the ability to assemble competing Users outside of the constructof a league. To demonstrate, an Instigating User A 10A may now inviteother users, here portrayed as other Users B-E 10B-E, to compete againstin fantasy play. (Necessarily any User must have a completed User's teamroster in order to play, but the number of users need not fall neatlyinto such as might be necessary to populate a bracket). Invited UsersB-E 10-B-E need not be persons having any prior relationship with theInstigating User A 10A. For this reason, the platform, in oneembodiment, can receive and add Users to forming groups of Users on arandom or on a referral basis. Similarly, one Instigating User 10A canparticipate in any number of distinct groups using the same roster 103Abecause of the capabilities of the engine to distinctly reconcilemultiple User team rosters 103A-E for each distinct group. Thecapabilities of the instant invention stem from the rosterreconciliation described below.

Once the Instigating User 10A has successfully created a User teamroster 103A, the User A 10A may elect to invite several other InvitedUsers 10B-E (by way of nonlimiting example) to play by using theplatform as described below. The Instigating User A 10A may also ask theplatform to assign or find other Invited Users 10B-E to play in thegroup as the Instigating User A 10A may request. Each registered User10A-E has a unique identification which allows the Instigating User A10A to send invitations to selected friends and acquaintances whoseidentification is known to the Instigating User A 10A through theplatform. In each instance of User selection, the platform delivers aninvitation to play to identified Invited Users 10B-E.

Once an invitation has been issued from Instigating User A 10A to eachother identified Invited User B-E, the Invited Users 10B-E are given theopportunity to accept the invitation. Such of them who accept become thecompeting group. For example, in FIG. 3, Invited User B 10B and InvitedUser C 10C each accepts the invitation; Invited User D 10D and InvitedUser E 10E each decline. The platform will receive the User team rosters103B, C along with the User A roster 103A for the roster reconciliationprocess to ultimately determine the Players that will represent eachUser 10A-C in fantasy competition. In this manner, the process fosters agaming community in the same manner as social video games in that theinvitation process serves to leverage the player's social network. Suchan invitation process allows the game to serve to build a community asplaying is only possible if a User “shares” his game with friends.

The User team roster each User has built out according to the abovediscussion merely represents that User's desired or proposed lineup.Much like the notes a General Manager takes into a draft for any ofseveral professional team sports, the User Team Roster is more like a“wish list” in that it does not reflect actual choices allowed relativeto each other User. Ultimately, the Players that will accrue points onbehalf of User or the Users actual lineup that will compete in fantasyplay will be determined by the process referred to as the “Stack RosterMatch Up.” In the Stack Roster Match Up, each User's team roster will betreated as a set of stacks, one for each position as is shown in FIG. 2relative to each of the positions. Within each stack, specific playersfrom a User's team roster are matched up with another User's stackrelative to the same position. In the event both Users have selected thesame player as their first choice, they will cancel one another out,resulting in neither User being able to utilize that particular playeragainst each other in active/actual game play. As a result of thecancelling move, the process moves to the second choice in the positionstack. This process will continue moving down the stack of players untileach user has a selection that is different from that of the other User.The first 2 players that do not matchup on a given tier will representtheir respective Users in that position for actual fantasy sports gameplay/competition.

A first example is shown in FIGS. 4A1, 4A2, and 4A3. As shown in FIG. 3,Instigating User A 10A, has invited Invited User B 10B and Invited UserC 10C to play and each has accepted. Users receive points byhead-to-head competition with each of the other Users in the group ofUsers by comparing the scores aggregated over the Season by the Playerseach User carries on his or her roster. As each of the Players arepresumed to accumulate distinct statistics over the Season, it isdesirable for Users to have distinct rosters. In competition between theUsers, the Users are grouped into competing pairs, and the rosters ofeach of the two Users in the competing pair of Users are reconciled suchthat relative to each other, each User has a distinct Player occupyingeach position on the User's roster.

Thus, to assign the available Players to each of the Users in acompeting pair to most closely meet their selections as expressed intheir User Roster, the method of reconciling is depicted in FIG. 4A1.Beginning with a hypothetical competing pair (“Stack Roster pair”)comprising the Instigating User A 10A, and the Invited User B 10B, aroster for competition relative to User B 10B is derived from the UserRoster 103A, Instigating User A 10A submitted, when that roster iscompared to the User Roster 103B, Invited User B 10B submitted.

As a result, each User has a roster relative to the other User in thecompeting pair which is constructed as shown. Position by position, eachof the User rosters such as roster 103A is compared to the roster 103Bof User B to yield specific Stack Rosters for each User relative to theother, in this case roster 103AB for User A relative to User B and 103BAfor User B relative to Instigating User A. In Instigating User A's Userroster 103A, the Player occupying a position is compared to the Playeron User B's User roster 103B at the same position and in thecorresponding choice in order to compare for matching selections. As inthis example, Instigating User A designated a first pick 103A1 and,probably by virtue of that Player's excellence in an earlier season,Invited User B designates the same player 103B1 as her first pick.According to the rules of the Stack Roster, relative to each other, thechoices 103A1 and 103B1 cancel, requiring the Stack Roster platform tomove to the second choices. Comparing second choices 103A2 to 103B2,Instigating User A and Invited User B have chosen the same Player againcausing those choices to cancel as between Instigating User A andInvited User B. Similarly the third choices 103A3 and 103B3 cancel as dofourth choices 103A4 and 103B4. It is not until the fifth choice whereInstigating User A and Invited User B select different Players. Thus,relative to each other, Instigating User A will play his fifth choice103A5 in his roster 103AB relative to Invited User B who will play herfifth choice 103B5 as the same is shown in her roster 103BA relative tothe Instigating User A.

The Stack Roster reconciler now moves, as shown in FIG. 4A2, to generatethe rosters of Instigating User A relative to Invited User C (rosters103AC and 103CA respectively) and Invited User C's relative toInstigating User A (rosters 103BC and 103CB respectively). In formingrosters 103AC and 103CA, having both selected the same first choice103A1 vs. 103C1 produces a match and neither User keeps the Player. TheStack Roster reconciler then moves to the second choices 103A2 and 103C2and finds them to be distinct. Position by position, in a like manner tothat of FIG. 4A1, rosters 103AC and 103CA are populated to fill a team.Importantly, while they are both derived from Instigating User A's Userroster 103A, in roster 103AB at this position, relative to Invited UserB, Instigating User A is playing 103A5 in this position; whereas inroster 103AC, relative to Invited User C, Instigating User A is playing103A2. There is no inconsistency in having the Instigating User Aplaying distinct rosters 103AB and 103AC in this competition, and to doso, adds an appealing ripple to such games.

Similarly, as depicted in FIG. 4A3, relative to Invited User C, InvitedUser B will play her second choice 103B2 against Invited User C's secondchoice 103C2, as shown in FIG. 4A3. Just as relative to Instigating UserA, Invited User C has expressed in her User team roster 103C, the samefirst choice 103C1 as has Invited User B as her first choice 103B1. Asthe rules dictate, these first choices cancel resulting in the selectionof the second choice relative to each other.

The Stack Roster Match Up process illustrated in FIG. 4A1, 4A2, and 4A3would continue in the same manner deriving the rosters for all gameparticipants relative to each other, progressing through all of thepositions until each of the Users have a full and complete Stack Rosterrelative to each other (By the convention above, User A has 103AB and103AC; User B, 103BA and 103BC; and User C, 103CA and 103CB.). TheUser(s) are then ready to engage in actual “consequential” fantasy gameplay against one another as shown in FIG. 4B, the outcome of which willbe determined by the performance of the actual Players that populateeach of the Users several rosters.

As is evident in FIG. 4B, play between three users actually results inthree distinct competitions for points: Instigating User A's roster 103Ais compared to Inviting User B's roster 103B in competition 115AB(taking into account the earlier described method of selection relativeto each User); Instigating User A's roster 103A against Invited User C'sroster 103C in competition 115AC; and Invited User B's roster 103B,against Invited User C's roster 103C in competition 115BC.

The competitions are each scored first as derived in each of thedistinct competing pairs. The Players (actual athletes on the respectiverosters) play out their regular sporting events and will accumulatestatistics that are scored on each of the rosters that contain theirnames over the course of the Season. Referring to FIG. 4C, in ahypothetical Season, thus, where Instigating User A's roster 103A iscompared to Invited User B's roster 103B (placed in competition 115AB),the two rosters are compared position by position to accumulate a totalacross the entirety of each User's rosters. Importantly, there is noreason why User A's roster 103A relative to User B's roster 103B wouldbe the same as User A's roster

In scoring the several rosters, we see Instigating User A's roster 103Aof Players accumulated a statistic of 129 point relative to Invited UserB's roster 103B which garnered 135 points. In competition 115AC whereInstigating User A's roster 103A is played against Invited User C'sroster 103C, Instigating User A's roster 103A scored 133 points againstInvited User C's roster 103C which scored 134 points to take the win.Invited User B's roster 103B is compared against Invited User C's roster103C in competition 115BC where the 134 points scored by User C's roster103C easily outdistanced the 126 points scored by User B's roster 103B.Other variants have been suggested where, for example, pitcher's uniquestatistics are weighted against those of catchers or fielders. Likewise,quarterbacks' unique statistics may be weighted to move the outcome morethan that of defensive centers.

While rules may vary without changing the essential nature of thefantasy game, the most straightforward embodiment of the inventionsimply totals points scored in each of the three competitions 115AB,115AC, and 115BC, yielding a win for Invited User C having a total of268 points, bettering both Instigating User A and Invited User B at therelevant position. While the winning or losing has been defined in thisparticular example by the performance of each User's selected Players atonly one position, the reader will certainly understand that rosterswill, in the main, consist of several positions in most sports. Thesenarrower examples have been provided simply to better explain the exactnature populating rosters and deriving scores.

FIGS. 5A-5C are example block diagrams illustrating data flows withinthe Stack Roster platform according to example embodiments. FIG. 5Aillustrates an arrangement of systems, modules, and devices according toone embodiment. The illustrated arrangement includes a Stack Rosterreconciler 200, a client device 201, a merchant system 202, and ascoring compiler system 203. The client device 201 operated by a User 10who is in the process of entering Player selection information for thepurposes of effectuating formation of a User team roster 103 (priorFigures) by or authentication of eligibility via a merchant system 202.The modules, systems, and devices illustrated with respect to FIGS.5A-5C may be differently arranged, operated, or constituted in otherembodiments. For example, the merchant system 202 and the scoringcompiler 203 may be merged as a single system and operated by a singleentity. In other embodiments, a third party provider may be present toeither authenticate a User or to replace one or more functions of themerchant system 202 or to provide the functions of the scoring compilersystem 203.

The client device 201 includes a User Team Roster interface (“UI”) 210and a Player Pool module 206. Examples of the UI 210 are described withrespect to FIGS. 1A-1C, above. The UI 210 is typically provided by themerchant system 202, such as when the UI 210 is implemented as part of aWeb page received from a Web-based e-commerce system hosted or providedby the merchant system 202. In other embodiments, the UI 210 may be partof a standalone client application, such as a Stack Roster desktop ormobile application.

The UI 210 includes a user interface element 212. The UI element 212 maybe any control, field, aspect, or other portion of the UI 210. Forexample, the UI element 212 may be a text field, a drop down menu, aselection group, a chooser, a button, a hidden field, or the like. Insome embodiments, the user 10 may interact with the UI element 212, suchas by clicking and dragging a movable control, editing a text field orpressing a button. In other embodiments, UI element 212 is inactive withrespect to direct user interaction. For example, the UI element 212 maybe a draggable element within a list control and/or a text element in adocument tree that represents the UI 210.

In the illustrated example, the User 10 specifies a Player for aposition via the UI element 212. Specifying other Users to interact withusing the Stack Roster platform may include entering (e.g., typing) auser's name, team name or other information into an editable text field.In other embodiments, User selection options may include interactingwith a drop down or other selection control to set or store the Userprofile information item (e.g., an address, phone number) in the UIelement 212.

Then, the User 10 specifies a particular fantasy sport in order toselect a Player pool from which to construct a roster 206 and also touniquely designate an identity for this User team roster to facilitatemultiple rosters within a given sport for the User. In the illustratedexample, the module 206 is received from the Stack roster reconciler200. For example, the module 206 may be a Web page or popup (possiblyincluding JavaScript or other code) displayed via a Web browser of theclient device 201. The Web page may include a user interface as well ascorresponding logic for facilitating the specification of extendedPlayer options. Example user interfaces of example modules are discussedin more detail with respect to FIGS. 1A-1C, above.

Once the User 10 has specified the unique User team roster 103, themodule 206 determines, generates, or prepares a series of slots orderedto various positions in accord with the User's 10 selection in a manneras described above. The indication may be a textual representation ofidentity of the User team roster, such as a fictitious name or code thatincludes an alphabetic string (e.g., “HAL”), a numeric string (e.g.,“1001”), an alphanumeric string (e.g., “APPT7”), a symbolic string(e.g., “%**!”), or some combination of the preceding. The indication ofthe User team roster may also or instead be or include a binary (e.g.,not human-readable) representation of the User team roster item. In someembodiments, the name or code may be generated by the UI based upon aname given by the User. In some instances, the selection of a particularsport may generate an indication specifically for that sport.

In another embodiment, the indication may be a network identifier thatidentifies (directly or indirectly) a network-accessible computingsystem or module that is configured to provide the Player Poolinformation for that selected sport upon request. For example, theindication may be a network address, a host name, a uniform resourceidentifier, or the like. The indication will typically further includean identifier, key, or other argument that can be used by thenetwork-accessible computing system to look up or otherwise access thesecond Player information.

The indication of the User team roster 103 is then entered into the UIelement 212. This may be a manual or automatic process. For example, themodule 206 may instruct the user 10 to enter (e.g., type or copy-paste)the indication of the User team roster 103 into the UI element 212. Inanother approach, the module 206 may automatically modify the UI element212 to include the indication of the User team roster. For example, themodule 206 may access the UI element 212 (e.g., by looking up itsidentifier in a DOM or other document data structure) and then modifythe data stored in the element 212 (e.g., a slots 107 in the User teamroster) to also include the indication of a Player selections by theUser 10.

Next, the User team roster UI 210 transmits the User team roster and theindication of the Player selections, data as graphically represented in103 (FIG. 2) to the merchant system 202. In some embodiments, theindication of the User team roster 103 will be transmitted along withsome or all of the User profile. For example, if the indication of theUser team roster includes a tag that has been inserted into datastructure of the User team roster, such that when the User team roster(including the tag) will be transmitted to the merchant system 202, themerchant system can verify the User's entitlement to play andconsequently transmitting the User's team roster to the Stack Rosterreconciler. The User team roster, may, in a similar manner contain a tagindicating identities of other Users selected to play in a particulargame using this User team roster 103. In other examples, the indicationmay be transmitted as a distinct element of a data structure allowingthe indication to be stored distinctly from the indication.

The merchant system 202 may then process the received User team roster,the invitations, and the User 10 profile. For example, the merchantsystem 202 may User address verification, profile modifications, orsimilar operations based on its role in assure User payment to play.Doing so may include parsing out or extracting the indication of theUser profile identification from User team roster so that the profile(or other information) stored therein can be isolated for purposes ofpayment verification or designating invited Users from a pool of suchdata stored in the User profile. In other embodiments, the merchantsystem 202 does not include any logic for processing (and does nototherwise interpret) one or more of the received User invitationinformation items. In such embodiments, the merchant system 202 mayreceive the invited User information with the User team roster thatincludes a tag as embedded within the invited and then forward orotherwise transmit the received items to some other system, such as theScoring Compiler 203. In other embodiments, the invited User informationis sent from the UI element 212 to the Stack Roster reconciler 200through network means without the Merchant System altering the datastructure.

After receiving and possibly processing the User team roster andincluded data items, the merchant system 202 may forward the itemsonwards to the Stack Roster reconciler for each of the invited Usersafter each User has been verified in the Merchant System 202. Userrosters 103 are reconciled in accord with the method of FIG. 4A in orderto cause the Scoring Compiler to initiate a new competition as requestedby the user 10. Once each User is verified, optionally to include thestatus of having paid, the reconciling of the rosters occurs.

At a FIG. 5B, the intermediate play is shown. As a result of the actionsof the Stack Roster reconciler 200, the fully reconciled rosters areeither returned to the Merchant system, or, in a non-depictedembodiment, the Stack Roster reconciler 200 sends the reconciled rostersto the Scoring Compiler 203. One of the functions of the ScoringCompiler 203 is to garner all statistics for all players, and in apresently preferred embodiment, third party vendors send the informationto the Scoring Compiler 203 using either of a “push” or a “pull”configuration to garner statistics on each of the Players represented byeach of the tiles in the Player pool 101 as shown in FIG. 1A. Incollecting all relevant statistics, the Scoring Compiler 203 serves as adata store of the latest and also historic statistics for each of thePlayers for perusal by the Users as well as for, ultimately, scoring thecompetition. In one embodiment, the tiles 105 A-E will include eitherthe statistics themselves or a link directing the UI Element 212 to thestatistics supplied by the Scoring Compiler 203 for display to informthe User in the Player selection process, as shown in FIGS. 1A through1C.

The Scoring Compiler 203 (or, as described above, the Merchant System202 in communication with the Scoring Compiler 203) then interprets thereceived statistics and performs the appropriate or necessary functionsto score each of the reconciled rosters in accord with the methoddepicted in FIGS. 4B and 4C, such as delivering intermediate scores tothe UI element 212 for display on the Client Device 201, displayingstandings, creating and storing specific User statistics such as scoringfor distinct positions in the roster 103. The Scoring Compiler 203 mayalso transmit to the Player Pool Module statistics to enable Users tocompile unique and new User team rosters for play, for example in MajorLeague Baseball™, a second season after the All-Star break.

FIG. 5C illustrates data flows in an embodiment to complete the season.The arrangement of components and systems shown in FIG. 5C is similar tothat of FIGS. 5A and B. In FIG. 5C, the Merchant System uses a networkidentifier to facilitate transmission of and access to extended all Userteam rosters and the reconciled Rosters as between several Users. In thecompletion of the competition The Merchant System 202, in an embodiment,compiles the statistical data for the season drawing from the ScoringCompiler 203 to generate and provide standings posted at a uniformresource identifier (“URI”) that identifies a network-accessible systemthat is configured to provide the standings to each User in response toa request. In other embodiments, the URI may be directly parsed todetermine an standings without interaction with a remote system. In someembodiments, a standings may be determined from the URI (e.g., as anembedded tag) and the UI element 212 directly, as standings may bedetermined by interacting based on the URI with a remote system.

Generating the URI by the Merchant System 202 may include interactingwith the Stack Roster reconciler 200. For example, the Merchant Systemmay transmit specified game information including User profiles to theStack Roster reconciler 200, and after receiving the data, retrieves theappropriate statistics from the Scoring Compiler 203 to generatestandings there for publication.

In an embodiment, the URI generated by the Merchant system 202 is thenentered into the UI element 212 for display, as discussed above. In thisexample, the merchant system 202 forwards the reconciled rosters and theURI to the UI Element. The Scoring Compiler 203 then determines thespecified those persons available for play based upon the setting ofsuch an option within the User's profile, determining the appropriateURI, and then by communicating, based on the URI, with the Stack Rosterreconciler 200. More particularly, the Scoring Compiler 203 transmits tothe facilitator 200 a request based on the URI. In an HTTP-basedembodiment, the request may be an HTTP GET that includes URI parameters,including any key-value pairs or other arguments that were part of theURI (e.g., id=12345). The Reconciler 200 then determines the scoringbased on the competition identifier, such as by looking up theparticular reconciled rosters based on a received identifier. The StackRoster reconciler 200 then transmits the standings back to the UIelement 212.

Note that the illustrated arrangement of modules may be differentlyconstituted in some embodiments. For example, the Player Pool module 206may be incorporated dynamically into the Scoring Compiler 203, asdiscussed with respect to FIG. 4B, above. As another example, themerchant system 202 and the Scoring Compiler 203 may be integrated as asingle system, rather than as distinct systems as shown. Furthermore,the Stack Roster reconciler 200 may be a component of one of the othermodules, such as the Scoring Compiler 203 or the merchant system 202.

In other embodiments, additional modules or systems may also be present.For example, some embodiments may include a third-party statistics(“TPL”) provider that stores the statistics on the Scoring Compiler 203to produce the resulting User scores.

Example embodiments described herein provide applications, tools, datastructures and other support to implement a Stack Roster reconciler tobe used to provide a platform for gaming. Other embodiments of thedescribed techniques may be used for other purposes, including forextending a user interface generally and/or using an existingcommunication protocol or data records to provide, carry, or transmitinformation beyond that which the protocol is designed to represent ortransport. In the following description, numerous specific details areset forth, such as data formats and code sequences, and the like, inorder to provide a thorough understanding of the described techniques.The embodiments described also can be practiced without some of thespecific details described herein, or with other specific details, suchas changes with respect to the ordering of the logic, different logic,or the like. Thus, the scope of the techniques and/or functionsdescribed are not limited by the particular order, selection, ordecomposition of aspects described with reference to any particularroutine, module, component, and the like.

Example Computing System Implementation

FIG. 6 is an example block diagram of an example computing system 300for implementing a Stack Roster reconciler 200 according to an exampleembodiment. In particular, FIG. 4 shows a computing system 300 that maybe utilized to implement a Stack Roster reconciler 200.

Note that one or more general purpose or special purpose computingsystems/devices suitably instructed may be used to implement the StackRoster reconciler 200. In addition, the computing system 300 maycomprise one or more distinct computing systems/devices and may spandistributed locations. Furthermore, each block shown may represent oneor more such blocks as appropriate to a specific embodiment or may becombined with other blocks. Also, the Stack Roster reconciler 200 may beimplemented in software, hardware, firmware, or in some combination toachieve the capabilities described herein.

In the embodiment shown, computing system 300 comprises a computermemory (“memory”) 301, a display 302, one or more Central ProcessingUnits (“CPU”) 303, Input/Output devices 304 (e.g., keyboard, mouse, CRTor LCD display, and the like), other computer-readable media 405, andnetwork connections 306 connected to a network 350. The Stack Rosterreconciler 200 is shown residing in memory 401. In other embodiments,some portion of the contents, some or all of the components of the StackRoster reconciler 200 may be stored on and/or transmitted over the othercomputer-readable media 305. The components of the Stack Rosterreconciler 200 preferably execute on one or more CPUs 303 and facilitatethe reconciliation of rosters and ultimately the scoring options asdescribed herein. Other code or programs 330 (e.g., an administrativeinterface, a Web server, and the like) and potentially other datarepositories, such as data repository 320, also reside in the memory301, and preferably execute on one or more CPUs 303. Of note, one ormore of the components in FIG. 6 may not be present in any specificimplementation. For example, some embodiments may not provide othercomputer-readable media 305 or a display 302.

The Stack Roster reconciler 200, in one embodiment, includes a widgetprovider 311, a tag manager 312, a user interface manager 315, aapplication program interface (API) 316, and a data store 318. In otherembodiments, functions performed by one or more of the illustratedcomponents may be performed externally to the Stack Roster reconciler200.

The Stack Roster reconciler 200 interacts via the network 350 withclient devices 201, merchant systems 202, and Scoring Compiler 203. Thenetwork 350 may be any combination of media (e.g., twisted pair,coaxial, fiber optic, radio frequency), hardware (e.g., routers,switches, repeaters, transceivers), and protocols (e.g., TCP/IP, UDP,Ethernet, Wi-Fi, WiMAX) that facilitate communication between remotelysituated humans and/or devices. In some embodiments, the network 350 maybe or include multiple distinct communication channels or mechanisms.The client devices 201 include mobile phones, smart phones, personaldigital assistants, laptop computers, tablet computers, desktopcomputers, and the like.

Users or others (e.g., customer service representatives) may use theclient devices 201 to construct User team rosters 103 or other items viathe merchant systems 202. The merchant systems 202 in turn prepare Userprofiles, invite Users to play, facilitate online chats and conveysstatistics garnered from the Scoring Compiler 203. The Scoring Compilers203 are used to, at least garner and store Player statistics fromsources including from third party vendors.

The widget provider 311 manages the storage and distribution of variousmodules, blocks, widgets, or the like to enable enhance functionalityand to increase the appeal of the game during play, such as an onlinechat between Users in a particular game to enable “smack talk” among theUsers. Another such widget might distribute latest Player interviewclips to Users having selected that Player on their User team roster.For example, a developer may create a new widget and provide the widgetto the Stack Roster reconciler 200 for storage and further distributionby the widget provider 311. The widget provider 311 may respond torequests received from client devices 201 or merchant systems 202 duringthe season. For example, a User may use one of the client devices 201 tointeract with a Web page that includes a link to a Bank page that givesUsers credits for later games based upon instantaneous standings, thelink causing a widget to be retrieved by the client device 201 from thewidget provider 311.

The tag manager 312 performs tag generation and translation services.For example, given a User and a stack roster, the tag manager 312 maygenerate a tag that is configured to represent that information. The tagmanager 312 may also, given a tag or other identifier, respond with theother User stack rosters specified by the identifier. In someembodiments, some or all of the logic of the tag manager may beincorporated into a widget or a Scoring Compiler 203.

The UI manager 315 provides a view and a controller that facilitate userinteraction with the Stack Roster reconciler 200 and its variouscomponents. For example, the UI manager 315 may provide interactiveaccess to the Stack Roster reconciler 200, such that users or systemscan obtain or configure widgets, generate tags, translate tags, and thelike. In some embodiments, access to the functionality of the UI manager415 may be provided via a Web server, possibly executing as one of theother programs 430. In such embodiments, a user operating a Web browser(or other client) executing on one of the devices/systems 201, 202,and/or 203 can interact with the Stack Roster reconciler 200 via the UImanager 315.

The API 316 provides programmatic access to one or more functions of theStack Roster reconciler 200. For example, the API 316 may provide aprogrammatic interface to one or more functions of the Stack Rosterreconciler 200 that may be invoked by one of the other programs 330 orsome other module. In this manner, the API 316 facilitates thedevelopment of third-party software, such as user interfaces, widgets,tag translation services (e.g., for integrating functions of the StackRoster reconciler 200 into Web applications), and the like. In addition,the API 316 may be in at least some embodiments invoked or otherwiseaccessed via remote entities, such as one of the Scoring Compilers 203,to access various functions of the Stack Roster reconciler 200.

The data store 318 is used by the other modules of the Stack Rosterreconciler 200 to store and/or communicate information. The componentsof the system 200 use the data store 318 to record various types ofinformation, including widgets and other controls, information aboutscoring and statistics provided by third-party vendors. Although thecomponents of the system 200 are described as communicating primarilythrough the data store 318, other communication mechanisms arecontemplated, including message passing, function calls, pipes, sockets,shared memory, and the like.

In an example embodiment, components/modules of the Stack Rosterreconciler 200 are implemented using standard programming techniques.For example, the Stack Roster reconciler 200 may be implemented as a“native” executable running on the CPU 303, along with one or morestatic or dynamic libraries. In other embodiments, the Stack Rosterreconciler 200 may be implemented as instructions processed by a virtualmachine. In general, a range of programming languages known in the artmay be employed for implementing such example embodiments, includingrepresentative implementations of various programming languageparadigms, including but not limited to, object-oriented (e.g., Java,C++, C#, Visual Basic.NET, Smalltalk, and the like), functional (e.g.,ML, Lisp, Scheme, and the like), procedural (e.g., C, Pascal, Ada,Modula, and the like), scripting (e.g., Perl, Ruby, Python, JavaScript,VBScript, and the like), and declarative (e.g., SQL, Prolog, and thelike).

The embodiments described above may also use either well-known orproprietary synchronous or asynchronous client-server computingtechniques. Also, the various components may be implemented using moremonolithic programming techniques, for example, as an executable runningon a single CPU computer system, or alternatively decomposed using avariety of structuring techniques known in the art, including but notlimited to, multiprogramming, multithreading, client-server, orpeer-to-peer, running on one or more computer systems each having one ormore CPUs. Some embodiments may execute concurrently and asynchronously,and communicate using message passing techniques. Equivalent synchronousembodiments are also supported. Also, other functions could beimplemented and/or performed by each component/module, and in differentorders, and by different components/modules, yet still achieve thedescribed functions.

In addition, programming interfaces to the data stored as part of theStack Roster reconciler 200, such as in the data store 318, can beavailable by standard mechanisms such as through C, C++, C#, and JavaAPIs; libraries for accessing files, databases, or other datarepositories; through scripting languages such as XML; or through Webservers, FTP servers, or other types of servers providing access tostored data. The data store 318 may be implemented as one or moredatabase systems, file systems, or any other technique for storing suchinformation, or any combination of the above, including implementationsusing distributed computing techniques.

Different configurations and locations of programs and data arecontemplated for use with techniques of described herein. In addition,the modules may reside on client or server systems that are physical orvirtual computing. Also, one or more of the modules may themselves bedistributed, pooled or otherwise grouped, such as for load balancing,reliability or security reasons. A variety of distributed computingtechniques are appropriate for implementing the components of theillustrated embodiments in a distributed manner including but notlimited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML-RPC,JAX-RPC, SOAP, and the like). Other variations are possible. Also, otherfunctionality could be provided by each component/module, or existingfunctionality could be distributed amongst the components/modules indifferent ways, yet still achieve the functions described herein.

Furthermore, in some embodiments, some or all of the components of theStack Roster reconciler 200 may be implemented or provided in othermanners, such as at least partially in firmware and/or hardware,including, but not limited to one or more application-specificintegrated circuits (“ASICs”), standard integrated circuits, controllersexecuting appropriate instructions, and including microcontrollersand/or embedded controllers, field-programmable gate arrays (“FPGAs”),complex programmable logic devices (“CPLDs”), and the like. Some or allof the system components and/or data structures may also be stored ascontents (e.g., as executable or other machine-readable softwareinstructions or structured data) on a computer-readable medium (e.g., asa hard disk; a memory; a computer network or cellular wireless networkor other data transmission medium; or a portable media article to beread by an appropriate drive or via an appropriate connection, such as aDVD or flash memory device) so as to enable or configure thecomputer-readable medium and/or one or more associated computing systemsor devices to execute or otherwise use or provide the contents toperform at least some of the described techniques. Some or all of thecomponents and/or data structures may be stored as non-transitorycontents on tangible, non-transitory storage mediums. Some or all of thesystem components and data structures may also be stored as data signals(e.g., by being encoded as part of a carrier wave or included as part ofan analog or digital propagated signal) on a variety ofcomputer-readable transmission mediums, which are then transmitted,including across wireless-based and wired/cable-based mediums, and maytake a variety of forms (e.g., as part of a single or multiplexed analogsignal, or as multiple discrete digital packets or frames). Suchcomputer program products may also take other forms in otherembodiments. Accordingly, embodiments of this disclosure may bepracticed with other computer system configurations.

While the preferred embodiment of the invention has been illustrated anddescribed, as noted above, many changes can be made without departingfrom the spirit and scope of the invention. Accordingly, the scope ofthe invention is not limited by the disclosure of the preferredembodiment. Instead, the invention should be determined entirely byreference to the claims that follow.

1. A method for playing a fantasy sport competition among a plurality ofUsers, the method comprising: by a client device having instructionsstored on a non-transitory computer readable medium, the device beingcommunicatively connected to a network: transmitting User selections tosuitably order Players in the User roster comprising a User prioritizedlist of Players according to positions, such that for each position theUser has reflected a plurality of choices in order of User preference;by the server having instructions stored on a non-transitory computerreadable medium, the server being communicatively connected to thenetwork: receiving Invited User rosters from each Invited User, eachInvited User roster comprising that Invited User's prioritized list ofPlayers according to positions; pairing the User with each Invited Userand each Invited User with each other to create Stack Roster pairings;and for each Stack Roster pairing, comparing the User's roster to theInvited User's roster for each position to create a single Player choicefor each of the User and the Invited User at each position to create aStack Roster for the pairing.
 2. The method of claim 1, furthercomprising; by the server: receiving Player statistics reflecting actualplay during a relevant period; and generating scores for each of theUser and the Invited User in the Stack Roster pairing according to thereceived Player statistics for each Player in the Stack Roster.
 3. Themethod of claim 2, further comprising: By the server: compiling thescores for the User and the Invited User for each Stack Roster pair, andgenerating standings based upon comparing compiled scores for each ofthe User and the Invited Users.
 4. The method of claim 1, whereintransmitting User selections to suitably order Players in the Userroster further comprises: by the client device: transmitting informationidentifying the User; and receiving a list of Players available for Userselection ordered according to Player positions; and by the server:generating the list of Players; and transmitting the list of Players. 5.The method of claim 1 wherein receiving Invited User rosters from eachadditional User further comprises: by the client device: transmittingUser selections designating Invited Users; and by the server:transmitting an invitation to each designated Invited User to generatean Invited User Player roster; and receiving from each additional Useran Invited User Player roster.
 6. The method of claim 5 wherein thetransmitting User selections designating additional Users furthercomprises: by the client device: selecting additional Users fordesignation from a list of available Users; and by the server:generating a list of available Users; and transmitting the list ofavailable Users to the User.
 7. A system for facilitating Users in theplay of fantasy sport games, the system comprising: a Merchant Systemresiding upon a server having instructions stored on a non-transitorycomputer readable medium, the server being communicatively connected tothe network, the Merchant System being configured to: receive a UserPlayer roster, comprising a plurality of Players listed according to aposition and in an order determined by a User's prioritized list ofPlayers for that position, from a plurality of registered Users eachusing a client device that is communicatively connected with thenetwork; and receiving a request from an Instigating User to invite atleast one of the plurality of registered Users to for a competing group;a Stack Roster reconciler, communicatively connected to the merchantsystem, comprises: a data store containing each of the User Playerrosters received from the merchant system; a memory having instructionsstored on a non-transitory computer readable medium; and a centralprocessing unit which, in response to the instructions performs a methodincluding: defining the Instigating User and each Invited User intoStack Roster pairings; reconciling the User rosters for each User ineach Stack Roster pairing relative to the other User in the Stack Rosterpairings into a Stack Roster; and calculating scores for each StackRoster, based upon Player statistics received from a Scoring Compilerrelevant to a defined period; and the Scoring Compiler, communicativecoupled to the Stack Roster reconciler and the merchant system andcomprising: a data store for receiving statistics for each Player ineach User Player roster; and a transmitting means to convey statisticsto the Stack Roster compiler.
 8. The system of claim 7, wherein theinstruction causing the center processing unit to reconcile the Userrosters comprise instructions to perform the method including: for eachUser in each Stack Roster pairing, retrieving each Users' prioritizedlist of Players for each position and commencing from a first priority:comparing the Players on each User's prioritized list for that priorityto determine if each is distinct; if the Players on each User'sprioritized list for that priority are distinct, assign each of thePlayers to the User in accord with that User's priority and move to thenext position; and if the Players on each User's prioritized list forthat priority are not distinct, the central processing unit will comparePlayers in a similar manner according to the next priority.
 9. Thesystem of claim 7 wherein, the merchant system receives calculatedscores for each User from the Stack Roster and transmits the scores toeach User at designated intervals.
 10. A computer having instructionsstored on a non-transitory computer readable medium, the device beingcommunicatively connected to a network to facilitate playing a fantasysport competition among a plurality of Users, the computer comprising:instructions stored on the non-transitory computer readable mediumcausing the central processing unit to perform the following operations:receiving User rosters from each User, each User roster comprising thatUser's prioritized list of Players according to positions; receivingfrom an Instigating User request for Invited Users; pairing the Userwith each Invited User and with each other Invited User to create StackRoster pairings; and for each Stack Roster pairing, comparing a firstUser's roster to a second User's roster for each position to create asingle Player choice for each of the Users at each position to create aStack Roster for the pairing.
 11. The computer of claim 10, furthercomprising; receiving Player statistics reflecting actual play during arelevant period; and generating scores for each of the User and theadditional User in the Stack Roster pairing according to the receivedPlayer statistics for each Player in the Stack Roster.
 12. The computerof claim 11, further comprising: By the server: compiling the scoreseach User in each Stack Roster pair according to the Stack Roster, andgenerating standings based upon comparing compiled scores for each ofthe User and the additional Users.
 13. The computer of claim 10, whereintransmitting User selections to suitably order Players in the Userroster further comprises: receiving information identifying theInstigating User; generating the list of Players; and transmitting thelist of Players.
 14. The computer of claim 10 wherein receivingadditional User rosters from each additional User further comprises:receiving a list of Invited Users; transmitting an invitation to eachdesignated additional User to generate an Invited User Player roster;and receiving from each Invited User an additional User Player roster.15. The computer of claim 10 wherein the transmitting User selectionsdesignating additional Users further comprises: generating a list ofavailable Users; transmitting the list of available Users to theInstigating User; receiving selections from the list of available Usersfrom the Instigating User; and transmitting an invitation to each of thedesignated Users.